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Special-Use Domain Names Problem Statement 
Abstract 


The policy defined in RFC 6761 for IANA registrations in the 
"Special-—Use Domain Names" registry has been shown, through 
experience, to present challenges that were not anticipated when RFC 
6761 was written. This memo presents a list, intended to be 
comprehensive, of the problems that have since been identified. In 
addition, it reviews the history of domain names and summarizes 
current IETF publications and some publications from other 
organizations relating to Special-Use Domain Names. 


This document should be considered required reading for IETF 
participants who wish to express an informed opinion on the topic of 
Special-Use Domain Names. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8244. 
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Les 


Introduction 


One of the key services required to use the Internet is name 
resolution. Name resolution is the process of translating a symbolic 
name into some object or set of objects to which the name refers, 
most typically one or more IP addresses. These names are often 
referred to as "domain names". When reading this document, care must 
be taken not to assume that the term domain name implies the use of 
the Domain Name System [RFC1034] for resolving these names. An 
excellent presentation on this topic can be found in Domain Names 
[DOMAIN-NAMES]. 


"Special-—Use Domain Names" [RFC6761] created the "Special-Use Domain 
Names" IANA registry [SDO-IANA-SUDR], defined policies for adding to 
the registry, and made some suggestions about how those policies 
might be implemented. Since the publication of RFC 6761, the IETF 
has been asked to designate several new Special-—Use Domain Names in 
this registry. During the evaluation process for these Special-Use 
Domain Names, the IETF encountered several different sorts of issues. 
Because of this, the IETF has decided to investigate the problem and 
decide if and how the process defined in RFC 6761 can be improved, or 
whether it should be deprecated. The IETF DNSOP Working Group 
charter was extended to include conducting a review of the process 
for adding names to the registry that is defined in RFC 6761. This 
document is a product of that review. 


Based on current ICANN and IETF practice, including RFC 6761, there 
are several different types of names in the root of the Domain 
Namespace: 


o Names reserved by the IETF for technical purposes 


o Names assigned by ICANN to the public DNS root; some names 
reserved by the IETF for technical purposes may appear in the 
global DNS root for reasons pertaining to the operation of the DNS 


o ICANN Reserved Names; names that may not be applied for as TLDs 
(see "Reserved Names" and "Treatment of Country or Territory 
Names" (Sections 2.2.1.2.1 and 2.2.1.4.1, respectively) of 
[SDO-ICANN-DAG]) . 


o Names used by other organizations without following established 
processes 


o Names that are unused and are available for assignment to one of 
the previous categories 
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This document presents a list, derived from a variety of sources, 
including discussion in the IETF DNSOP Working Group, of the problems 
associated with the assignment of Special-Use Domain Names. The list 
is intended to be an unfiltered compilation of issues. In support of 
its analysis of the particular set of issues described here, the 
document also includes descriptions of existing practice as it 
relates to the use of domain names, a brief history of domain names, 
and some observations by various IETF participants who have 
experience with various aspects of the current situation. 


2. Terminology 


This document uses the terminology from RFC 7719 [RFC7719]. Other 
terms used in this document are defined here: 


Domain Name: This document uses the term "domain name" as defined in 
Section 2 of RFC 7719 [RFC7719]. 


Domain Namespace: The set of all possible domain names. 


Special-Use Domain Name: A domain name listed in the "Special-Use 
Domain Names" registry [SDO-IANA-SUDR]. 


For the sake of brevity, this document uses some abbreviations, which 
are expanded here: 


IANA: Internet Assigned Numbers Authority 
ICANN: Internet Corporation for Assigned Names and Numbers 
TLD: Top-Level Domain, as defined in Section 2 of RFC 7719 
[RFC7719] 
gTLD: Generic Top-Level Domain (see Section 2 of RFC 2352 
[RFC2352]) 
3. Problems Associated with Special-Use Domain Names 


This section presents a list of problems that have been identified 
with respect to the assignment of Special-Use Domain Names. 

Solutions to these problems, including their costs or trade-offs, are 
out of scope for this document and will be covered in a separate 
document. New problems that might be created in the process of 
solving problems described in this document are also out of scope: 
these problems are expected to be addressed in the process of 
evaluating potential solutions. 
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Special-Use Domain Names exist to solve a variety of problems. This 
document has two goals: enumerate all of the problems that have been 
identified to which Special-Use Domain Names are a solution and 
enumerate all of the problems that have been raised in the process of 
trying to use RFC 6761 as it was intended. As some of those problems 
may fall into both categories, this document makes no attempt to 
categorize the problems. 


There is a broad diversity of opinion about this set of problems. 

Not every participant agrees that each of the problems enumerated in 
this document is actually a problem. This document takes no position 
on the relative validity of the various problems that have been 
enumerated, nor on the organization responsible for addressing each 
individual problem, if it is to be addressed. This document only 
enumerates the problems, provides the reader with context for 
thinking about them, and provides a context for future discussion of 
solutions, regardless of whether such solutions may work for IETF, 
ICANN, IANA, or some other group. 


The list of problems is not presented in order of importance; numbers 
are assigned so that each problem can easily be referenced by number, 
not to indicate priority. The list of problems is as follows: 


alts Although the IETF and ICANN have a liaison relationship through 
which special-use allocations can be discussed, there exists no 
formal process for coordinating these allocations (see 
Section 4.1.3). The lack of coordination complicates the 
management of the root of the Domain Namespace and could lead to 
conflicts in name assignments [SDO-ICANN-SACO090]. 


2. There is no explicit scoping as to what can constitute a 
"technical use" [RFC2860] and what cannot; there is also no 
consensus within the IETF as to what this term means. 


33 Not all developers of protocols on the Internet agree that 
authority over the entire Domain Namespace should reside solely 
with the IETF and ICANN. 


4. Although the IETF and ICANN nominally have authority over this 
namespace, neither organization can enforce that authority over 
any third party who wants to just start using a subset of the 
namespace. Such parties may observe that the IETF has never 
asserted control or authority over what protocols are "allowed" 
on the Internet, and that the principle of "permissionless 
innovation" suggests there should be a way for people to include 
new uses of domain names in new protocols and applications. 
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J; Organizations do in fact sometimes use subsets of the Domain 
Namespace without following established processes. Reasons a 
third party might do this include: 


1. Lack of knowledge that a process exists for assigning such 
names. 


2. Intended use is covered by the gTLD process [SDO-ICANN-DAG], 
but no gTLD process is ongoing. 


3. Intended use is covered by the gTLD process, but the third 
party doesn’t want to pay a fee. 


4. Intended use is covered by some IETF process, but the third 
party doesn’t want to follow the process. 


5. Intended use is covered by an ICANN or IETF process, but the 
third party expects that the outcome will be refusal or non- 
action. 


6. Lack of knowledge that a name intended to be used only 
locally may nevertheless leak. 


7. Lack of knowledge that a name used locally with informal 
allocation may subsequently be allocated formally, creating 
operational problems. 


6. There is demand for more than one name resolution protocol for 
domain names. Domain names contain no metadata to indicate 
which protocol to use to resolve them. Domain name resolution 
APIs do not provide a way to specify which protocol to use. 


Ks When a Special-Use Domain Name is added to the "Special-Use 
Domain Names" registry, not all software that processes such 
names will understand the special use of that name. In many 
cases, name resolution software will use the Domain Name System 
for resolution of names not known to have a special use. 
Consequently, any such use will result in queries for Special- 
Use Domain Names being sent to Domain Name System authoritative 
servers. These queries may constitute an operational problem 
for operators of root zone authoritative name servers. These 
queries may also inadvertently reveal private information 
through the contents of the query, which is a privacy 
consideration. 
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8. Some protocol developers have assumed that they could not 
succeed in getting a name assigned through the IETF using the 
process defined in RFC 6761. This is because when the IETF has 
attempted to follow the process defined in RFC 6761, it has been 
slow and uncertain. For example, the process of assigning the 
first new name (’.local’) using the process defined in RFC 6761 
took more than ten years from beginning to end: longer by a 
factor of ten than any other part of the protocol development 
process (largely because this ten years included time to develop 
the process as well as use it). Other uses of the process have 
proceeded more smoothly, but there is a reasonably justified 
perception that using this process is likely to be slow and 
difficult, with an uncertain outcome. 


9. There is strong resistance within the IETF to assigning domain 
names to resolution systems outside of the DNS, for a variety of 
reasons: 


1. It requires a mechanism for identifying which set of 
resolution processes is required in order to resolve a 
particular name. 


2. Assertion of authority: there is a sense that the Domain 
Namespace is "owned" by the IETF or by ICANN, so, if a name 
is claimed without following their processes, the person or 
entity that claimed that name should suffer some consequence 
that would, presumably, deter future circumvention of the 
official processes. 


3. More than one name resolution protocol is bad, in the sense 
that a single protocol is less complicated to implement and 
deploy. 


4. The semantics of alternative resolution protocols may differ 
from the DNS protocol; DNS has the concept of RRtypes, 
whereas other protocols may not support RRtypes or may 
support some entirely different data structuring mechanism. 


5. If there is an IETF process through which a TLD can be 
assigned at zero cost other than time, this process will be 
used as an alternative to the more costly process of getting 
the name registered through ICANN. 


6. A name might be assigned for a particular purpose when a 
more general use of the name would be more beneficial. 
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7. If the IETF assigns a name that some third party or parties 
believe belongs to them in some way, the IETF could become 
embroiled in an expensive dispute with those parties. 


10. If there were no process for assigning names for technical use 
through the IETF, there is a concern that protocols that require 
such names would not be able to get them. 


11. In some cases where the IETF has made assignments through the 

process defined in RFC 6761, technical mistakes have been made 
due to misunderstandings as to the actual process that RFC 6761 
specifies (e.g., treating the list of suggested considerations 
for assigning a name as a set of requirements, all of which must 
be met). In other cases, the IETF has made de facto assignments 
of Special-Use Domain Names without following the process in RFC 
6761 (see [RFC7050] and [RFC7788]). 


12. There are several Top-Level Domain Names that are in use without 
due process for a variety of purposes. The status of these 
names need to be clarified and recorded to avoid future disputes 
about their use [SDO-ICANN-COLL]. 


13. In principle, the process defined in RFC 6761 could be used to 
document the existence of domain names that are not safe to 
assign and provide information on how those names are used in 
practice. However, attempts to use RFC 6761 to accomplish this 
documentation have not been successful (for example, see 
"Additional Reserved Top Level Domains" [RESERVED-TLDS] and 
Section 4.2.7 of this document). One side effect of the lack of 
documentation is that any mitigation effect on the root name 
servers or on privacy considerations has been missed. 


14. A domain name can be identified as either a DNS name by placing 
it in the DNS zone(s) or a Special-Use Domain Name by adding it 
to the IANA registry. Some names are in both places; for 
example, some locally served zone names are in DNS zones and 
documented in the "Special-Use Domain Names" registry. At 
present, the only way a domain name can be added to the 
"Special-Use Domain Name" registry is for the IETF to take 
responsibility for the name and designate it for "technical 
use". There are other potential uses for domain names that 
should be recorded in the registry, but for which the IETF 
should not take responsibility. 


15. In some cases, the IETF may see the need to document that a name 
is in use without claiming that the use of the name is the 
IETF’s particular use of the name. No mechanism exists in the 
current registry to mark names in this way. 
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16. During any of the review stages of a document, there is no 
formal process in which a check is made to ensure that the 
document does not unintentionally violate the IETF process for 
adding Special-Use Domain Names to the registry, as was the 
case, for example, in RFC 7788 [RFC7788]. 


17. Use of the registry is inconsistent -- some Special-Use Domain 
Name RFCs specifically add registry entries, some don’t; some 
specify how and whether special-use name delegations should be 
done, some don’t. 


18. There exists no safe, non-process-violating mechanism for ad hoc 
assignment of Special-—Use Domain Names. 


19. It is generally assumed that protocols that need a Special-Use 
Domain Name need a mnemonic, single-label, human-readable 
Special-Use Domain Name for use in user interfaces such as 
command lines or URL entry fields. While this assumption is 
correct in some cases, it is likely not correct in all cases, 
for example, in applications where the domain name is never 
visible to a user. 


20. RFC 6761 uses the term "domain name" to describe the thing for 
which special uses are registered. This creates a great deal of 
confusion because some readers take "domain name" to imply the 
use of the DNS protocol. 


21. The use of DNSSEC with Special-Use Domain Names is an open 
issue. There is no consensus or guidance about how to use 
DNSSEC with various classes of Special-Use Domain Names. 
Considerations in the use of DNSSEC with Special-Use Domain 
Names include: 


1. What class of Special—Use Domain Name is under 
consideration: non-DNS, locally served zone, or other? 


2. Does the Special-Use Domain Name require a delegation in the 
root zone; if so, should that delegation be signed or not? 
If there is no delegation, then this will be treated by 
validating resolvers as a secure denial of existence for 
that zone. This would not be appropriate for a name being 
resolved using the DNS protocol. 


3. A process would be required through which the IETF can cause 
a delegation in the root zone to be instantiated. 


4. What are the recommended practices for using DNS with the 
specific Special-—Use Domain Name? 
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The above list represents the current understanding of the authors as 
to the complete set of problems that have been identified during 
discussion by the working group on this topic. The remainder of this 
document provides additional context that will be needed for 
reasoning related to these problems. 


4. Existing Practice regarding Special—-Use Domain Names 


There are three primary (see Section 4.1) and numerous secondary 
(Section 4.2) documents to consider when thinking about the Special- 
Use Domain Names process. 


How names are resolved is ambiguous, in the sense that some names are 
Special-Use Domain Names that require special handling and some names 
can be resolved using the DNS protocol with no special handling. 


The assignment of Internet Names is not under the sole control of any 
one organization. The IETF has authority in some cases, but only 
with respect to "technical uses". At present, ICANN is the 
designated administrator of the root zone; but generally not of zones 
other than the root zone. Neither of these authorities can, in any 
practical sense, exclude the practice of ad hoc use of names. 
Unauthorized use of domain names can be accomplished by any entity 
that has control over one or more name servers or resolvers, in the 
context of any hosts and services that entity operates. It can also 
be accomplished by authors of software who decide that a Special-Use 
Domain Name is the right way to indicate the use of an alternate 
resolution mechanism. 


4.1. Primary Special-Use Domain Name Documents 


The primary documents are considered primary because they directly 
address the IETF’s past thoughts on this topic in a general way, and 
also because they describe what the IETF does in practice. 


4.1.1. IAB Technical Comment on the Unique DNS Root 


[RFC2826] is not an IETF consensus document, and it appears to have 
been written to address a different problem than the Special-Use 
Domain Name problem. However, it speaks directly to several of the 
key issues that must be considered, and, coming as it does from the 
IAB, it is rightly treated as having significant authority despite 
not being an IETF consensus document. 


This document should be considered required reading for IETF 
participants who wish to express an informed opinion on the topic of 
Special-Use Domain Names. The main points that appear relevant to 
the Special—-Use Domain Names problem are: 
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We 


Lemon, 


The Internet requires a globally unique namespace: a namespace in 
which any given name refers to the same information (has the same 
meaning) no matter who requests that information and no matter 
from which specific name server they request it. 


Private networks may operate private namespaces, with names that 
have meanings only locally (within the private network), but they 
still require that names in the public namespace be globally 
unique. 


The Domain Name System [RFC1035] is not the only protocol that may 
be used for resolving domain names. 


Users cannot be assumed to know how to distinguish between 
symbolic references that have local meaning and references that 
have global meaning. Therefore, users may share references that 
incorporate domain names with no global meaning (for example, a 
URL of 'http://mysite.example.corp’, where ’example.corp’ is a 
domain used privately and informally as described in 
[SDO-ICANN-COLL]). 


While such a reference in the user’s context refers to the object 
the user wishes to share, when the reference is used ina 
different context, it could refer either to some different object 
in the recipient’s context or to no object at all. The effect of 
this reference escaping the context in which it is valid is that 
the user’s intended communication will not be able to be 
understood by the recipients of the communication. 


This same problem can also occur when a single user copies a name 
from one context in which it has one meaning into a different 
context in which it has a different meaning -- for example, 
copying a ’.onion’ domain name out of a Tor Browser [TOR], where 
it has meaning, and pasting this name into an SSH client that 
doesn’t support connecting over the Tor network. 


can summarize the advice in this document as follows: 


Domain names with unambiguous global meaning are preferable to 
domain names with local meaning that will be ambiguous. 
Nevertheless, both globally meaningful and locally special names 
are in use and must be supported. 


At the time of the writing of this document, the IAB was of the 


opinion that there might well be more than one name resolution 
protocol used to resolve domain names. 
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4.1 


-2. Special-Use Domain Names 


The second important document is "Special-Use Domain Names" 
[RFC6761]. RFC 6761 represents the current IETF consensus on 
designating and recording Special-Use Domain Names. The IETF has 
experienced problems with the designation process described in RFC 
6761; these concerns motivate this document. Familiarity with RFC 
6761 is a prerequisite for having an informed opinion on the topic of 
Special-Use Domain Names. 


RFC 6761 defines two aspects of Special-Use Domain Names: designating 
a domain name to have a special purpose and registering that special 
use in the "Special-Use Domain Names" registry. The designation 
process is defined in a single sentence (RFC 6761, Section 4): 


If it is determined that special handling of a name is required in 
order to implement some desired new functionality, then an IETF 
"Standards Action" or "IESG Approval" specification [RFC5226] MUST 
be published describing the new functionality. 


This sentence requires that any designation of a Special-—Use Domain 
Name is subject to the same open review and consensus process as used 
to produce and publish all other IETF specifications. 


The registration process is a purely mechanical process, in which the 
existence of the newly designated Special-—Use Domain Name is 
recorded, with a pointer to a section in the relevant specification 
document that defines the ways in which special handling is to be 
applied to the name. 


RFC 6761 provides the process whereby "Multicast DNS" [RFC6762] 
designated ’.local’ as a Special-Use Domain Name and included it in 
the "Special—-Use Domain Names" registry. RFC 6761 also enumerates a 
set of names that were previously used or defined to have special 
uses prior to its publication. Since there had been no registry for 
these names prior to the publication of RFC 6761, the documents 
defining these names could not have added them to the registry. 


Several important points to think about with respect to RFC 6761 are: 


O A Special-Use Domain Name may be a name that should be resolved 
using the DNS protocol with no special handling. An example of 
this is ’in-addr.arpa’ (which is an example of a Special-Use 
Domain Name that is not a TLD). 
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o A Special-Use Domain Name may be a name that is resolved using the 
DNS protocol and that requires no special handling in the stub 
resolver but that requires special handling in the recursive 
resolver. An example of this would be '10.in-addr.arpa.’. 


o A Special-Use Domain Name may be a name that requires special 
handling in the stub resolver. An example would be a Special-—Use 
Top-Level Domain Name like ’.local’, which acts as a signal to 
indicate that the local stub resolver should use a non-DNS 
protocol for name resolution. 


o The current IETF consensus (from a process perspective, not 
necessarily from the perspective of what would be consensus if the 
IETF were to attempt to produce a new consensus document) is that 
all of these purposes for Special-Use Domain Names are valid. 


In this case, the term "stub resolver" does not mean "DNS protocol 
stub resolver". The stub resolver is the entity within a particular 
software stack that takes a question about a domain name and answers 
it. One way a stub resolver can answer such a question is using the 
DNS protocol; however, it is in the stub resolver (as we are using 
the term here) that the decision as to whether to use a protocol (and 
if so, which protocol) or a local database of some sort is made. 


RFC 6761 does not limit Special-Use Domain Names to TLDs. However, 
at present, all Special-Use Domain Names registered in the "Special- 
Use Domain Names" registry [SDO-IANA-SUDR] either are intended to be 
resolved using the DNS protocol, are TLDs, or are both. That is, at 
present there exist no Special-Use Domain Names that require special 
handling by stub resolvers and which are not at the top level of the 
naming hierarchy. 


One point to take from this is that there is already a requirement in 
RFC 6762 that when a stub resolver encounters the special label, 
‘local’ as the rightmost label of a domain name, it can only use the 
Multicast DNS (mDNS) protocol to resolve that domain name. 


4.1.3. MoU Concerning the Technical Work of IANA 


There exists a Memorandum of Understanding (MoU) [RFC2860] between 
the IETF and ICANN that discusses how names and numbers will be 
managed through IANA. This document is important to the discussion 
of Special-Use Domain Names because, while it delegates authority for 
managing the DNS Namespace generally to ICANN, it reserves to the 
IETF the authority that is then formalized in RFC 6761. RFC 2860 
specifically states: 
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Note that (a) assignments of domain names for technical uses (such 
as domain names for inverse DNS lookup), (b) assignments of 
specialised address blocks (such as multicast or anycast blocks), 
and (c) experimental assignments are not considered to be policy 
issues, and shall remain subject to the provisions of this 

Section 4. 


The above text is an addendum to the following: 


Two particular assigned spaces present policy issues in addition 
to the technical considerations specified by the IETF: the 
assignment of domain names, and the assignment of IP address 
blocks. These policy issues are outside the scope of this MOU. 


The assignment of names in the DNS root zone, and the management of 
the Domain Namespace, is by default a function that is performed by 
ICANN. However, the MoU specifically exempts domain names assigned 
for technical use and uses the example of domains used for inverse 
DNS lookup. Both ’in-addr.arpa’ and ’ip6.arpa’ are in the "Special- 
Use Domain Names" registry. 


Implicit in the MoU is the fact that the IETF and ICANN retain, 
between them, sole authority for assigning any names from the Domain 
Namespace. Both the IETF and ICANN have internal processes for 
making such assignments. 


The point here is not to say what the implications of this statement 
in the MoU are, but rather to call the reader’s attention to the 
existence of this statement. 


4.1.4. Liaison Statement on Technical Use of Domain Names 


When the IETF received processing requests to add names to the 
"Special-—Use Domain Names" registry, as documented in [RESERVED-TLDS] 
and [P2P-DOMAIN-NAMES], the IETF chartered a review of the process 
defined in RFC 6761 for adding names to the registry (as explained 
earlier). The IETF sent a liaison statement [SDO-IAB-ICANN-LS] to 
ICANN to notify them of the review, affirm that the discussion would 
be "open and transparent to participation by interested parties", and 
explicitly invite members of the ICANN community to participate. 
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4.1.5. IAB Statement on the Registration of Special Use Names in the 
ARPA Domain 


As part of the process of resolving the controversy mentioned in 
Section 4.2.7, the IAB issued a statement saying, in part: 


There is currently no process defined with ICANN for special use 
names to be delegated in the root zone; it has seemed likely to take 
significant effort to create one. The IAB has noted that .arpa can 
be used "for technical infrastructure established by IETF standards" 
[SDO-IAB-SUDN-REG] . 


Given the lack of an established process with ICANN, IETF documents 
cannot reserve names in the root of the DNS namespace if those names 
are to be delegated (that is, used by the DNS protocol). It would be 
possible to work with ICANN to develop a process for such 
delegations, but the success of that joint work, and the amount of 
time it would take, would still be uncertain. 


4.2. Secondary Documents Relating to the Special-Use Domain Name 
Question 


In addition to these documents, there are several others with which 
participants in this discussion should be familiar. 


4.2.1. Multicast DNS 


Multicast DNS [RFC6762] defines the Multicast DNS protocol, which 
uses the ’.local’ Special-Use Top-Level Domain Name. Section 3 
describes the semantics of "multicast DNS names". It is of 
considerable historical importance to note that the -00 version of 
the document that eventually became RFC 6762, an individual 
submission, was published in July of 2001. The version posted at 
that time contains substantially the same text in Section 3 as RFC 
6762 did when published and was discussed in the DNSEXT Working Group 
at IETF 51 in August of 2001 [IETF-PRO-51]. The July 2001 draft 
designated ’.local.arpa’ as the Special-Use Domain Name. This idea 
was strongly opposed by DNSEXT Working Group participants, and as a 
result, the author eventually switched to using ’.local’. 


The history of RFC 6762 is documented in substantial detail in 
Appendix H of RFC 6762; some notable milestones include the initial 
proposal to replace AppleTalk’s Name Binding Protocol (NBP) in July 
1997, the chartering of the Zeroconf Working Group in September 1999, 
and the assignment of a multicast address for link-local name 
discovery in April of 2000. A companion requirements document, 
eventually published as [RFC6760], was first published in September 
of 2001. 
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The point of mentioning these dates is so that discussions involving 
the time when the ’.local’ domain was first deployed, and the context 
in which it was deployed, may be properly informed. 


-2. The ’.onion’ Special-Use Top-Level Domain Name 


The ’.onion’ Special-Use Top-Level Domain Name [RFC7686] is important 
because it is the most recent IETF action on the topic of Special-Use 
Domain Names; although it does not set a new policy, the mere fact of 
its publication is worth thinking about. 


Two important points to consider about this document are that: 
o The IETF gained consensus to publish it. 


o Devising a resolution to the situation was constrained by at least 
two factors. First, there was no process for allocating Special- 
Use Domain Names at the time that the ’.onion’ project started 
using the name; at the time, and since the scope of use of the 
name was expected to be very constrained, the developers chose to 
allocate it unilaterally rather than asking the IETF or some other 
Standards Development Organization (SDO) to create a new process. 


Second, for some time, the CA/Browser Forum [SDO-CABF] had been 
issuing certificates for what they referred to as "internal 
names". Internal names are names allocated unilaterally for use 
in site-specific contexts. Issuing certificates for such names 
came to be considered problematic, since no formal process for 
testing the validity of such names existed. Consequently, the CA/ 
Browser Forum decided to phase out the use of such names in 
certificates [SDO-CABF-INT] and set a deadline after which no new 
certificates for such names would be issued [SDO-CABF-DEADLINE]. 
Because the ’.onion’ domain was allocated unilaterally, this would 
mean that certificates for subdomains of ’.onion’ could no longer 
be issued. 


The IETF’s designation of ’.onion’ as a Special-Use Top-Level 
Domain Name was needed to facilitate the development of a 
certificate issuance process specific to ’.onion’ domain names 
[SDO-CABF-BALLOT144]. 


3. Locally Served DNS Zones 


"Locally Served DNS Zones" [RFC6303] describes a particular use case 
for zones that exist by definition and that are resolved using the 
DNS protocol, but that cannot have a global meaning because the host 
IP addresses they reference are not unique. This applies toa 
variety of addresses, including private IPv4 addresses [RFC1918], 
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"Unique Local IPv6 Unicast Addresses" [RFC4193] (in which this 
practice was first described), and "IANA-Reserved IPv4 Prefix for 
Shared Address Space" [RFC6598]. 


This use case is distinct from the use case for Special-Use Domain 
Names like ’.local’ and ’.onion’ in that the names are resolved using 
the DNS protocol (but they do require extensions or exceptions to the 
usual DNS resolution to enforce resolution in a local context rather 
than the global DNS context). It shares the problem that such names 
can be assumed neither to be unique across all contexts nor 
functional for all Internet-connected hosts. 


4.2.4. Name Collision in the DNS 


"Name Collision in the DNS" [SDO-ICANN-COLL] is a study that was 
commissioned by ICANN in an attempt to characterize the potential 
risk to the Internet of adding global DNS delegations for names that 
were not previously delegated in the DNS and were not reserved under 
any RFC, but were also known to be (in the case of ’.home’) or 
surmised to be (in the case of ’.corp’) in significant use for 
Special-Use-type reasons (local scope DNS or other resolution 
protocols altogether). 


4.2.5. SSAC Advisory on the Stability of the Domain Namespace 


The ICANN Security and Stability Advisory Committee (SSAC) 
[SDO-ICANN-SSAC] specification "SSAC Advisory on the Stability of the 
Domain Namespace" [SDO-ICANN-SAC090] reports on some issues 
surrounding the conflicting uses, interested parties, and processes 
related to the Domain Namespace. The specification recommends the 
development of collaborative processes among the various interested 
parties to coordinate their activities related to the Domain 
Namespace. 


4.2.6. Discovery of the IPv6 Prefix Used for IPv6é Address Synthesis 


"Discovery of the IPv6é Prefix Used for IPv6 Address Synthesis" 
[RFC7050] is an example of a document that successfully used the 
process in RFC 6761 to designate ’.ipv4only.arpa’ as a Special-Use 
Domain Name; in this case, the process worked smoothly and without 
controversy. 


Unfortunately, while the IETF process worked smoothly, in the sense 
that there was little controversy or delay in approving the new use, 
it did not work correctly: the name ’ipv4only.arpa’ was never added 
to the "Special-Use Domain Names" registry. This appears to have 
happened because the document did not explicitly request the addition 
of an entry for ’ipv4only.arpa’ in the "Special-Use Domain Names" 
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registry. This is an illustration of one of the problems that we 
have with the process in RFC 6761: it is apparently fairly easy to 
miss the step of adding the name to the registry. 


4.2.7. Additional Reserved Top-Level Domains 


"Additional Reserved Top Level Domains" [RESERVED-TLDS] is an example 
of a document that attempted to reserve several TLDs identified by 
ICANN as particularly at risk for collision as Special-Use Domain 
Names with no documented use. This attempt failed. 


Although the aforementioned document failed to gain consensus to be 
published, the need it was intended to fill still exists. 
Unfortunately, although a fair amount is known about the use of these 
names, no RFC exists that describes how they are used and why it 
would be a problem to delegate them. Additionally, to the extent 
that the uses being made of these names are valid, no document exists 
indicating when it might make sense to use them and when it would not 
make sense to use them. 


RFC 7788 [RFC7788] defines the Top-Level Domain Name ’.home’ for use 
as the default name for name resolution relative to a home network 
context. Although, as defined in RFC 7788, ’.home’ is a Special-Use 
Domain Name, RFC 7788 did not follow the process specified in RFC 
6761: it did not request that ’.home’ be added to the "Special-Use 
Domain Names" registry. This was recognized as a mistake and 
resulted in the posting of an errata report [Err4677]. Additionally, 
’ home’ is an example of an attempt to reuse a domain name that has 
already been put into use for other purposes without following 
established processes [SDO-ICANN-COLL], which further complicates the 
Situation. At the time RFC 8244 was written, the IETF was developing 
a solution to this problem. 


5. History 


A newcomer to the problem of resolving domain names may be under the 
impression that the DNS sprang fully formed directly from Paul 
Mockapetris’ head (as was the birth of Athena in Greek Mythology). 
This is not the case. At the time the IAB technical document was 
written [RFC2826], memories would have been fresh of the evolutionary 
process that led to DNS’ dominance as a protocol for domain name 
resolution. 


In fact, in the early days of the Internet, hostnames were resolved 
using a text file, HOSTS.TXT, which was maintained by a central 
authority, the Network Information Center, and distributed to all 
hosts on the Internet using the File Transfer Protocol (FTP) 
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[RFC959]. The inefficiency of this process is cited as a reason for 
the development of the DNS [RFC882] [RFC883] in 1983. 


However, the transition from HOSTS.TXT to the DNS was not smooth. 
For example, Sun Microsystems’ Network Information System (NIS) 
[CORP-SUN-NIS], at the time known as Yellow Pages, was an active 
competitor to the DNS, although it failed to provide a complete 
solution to the global naming problem. 


Another example was NetBIOS Name Service, also known as WINS 
[RFC1002]. This protocol was used mostly by Microsoft Windows 
machines, but also by open-source BSD and Linux operating systems to 
do name resolution using Microsoft’s own name resolution protocol. 


Most modern operating systems can still use the ’/etc/hosts’ file for 
name resolution. Many still have a name service switch that can be 
configured on the host to resolve some domains using the NIS or WINS. 
Most have the capability to resolve names using mDNS by recognizing 
the special meaning of the ’.local’ Special-Use Top-Level Domain 
Name. 


The Sun Microsystems model of having private domains within a 
corporate site, while supporting the global Domain Name System for 
off-site, persisted even after the NIS protocol fell into disuse. 
Microsoft used to recommend that site administrators use a "private" 
TLD for internal use, and this practice was very much a part of the 
zeitgeist at the time (see Section 5.1 of [SDO-ICANN-COLL] and 
Appendix G of [RFC6762]). This attitude is at the root of the 
widespread practice of simply picking an apparently unused TLD and 
using it for experimental purposes, which persists even at the time 
of writing of this memo. 


This history is being presented because discussions about Special-Use 
Domain Names in the IETF often come down to the question of why users 
of new name resolution protocols choose to use domain names rather 
than using some other naming concept that doesn’t overlap with the 
namespace that, in modern times is, by default, resolved using the 
DNS. 


The answer is that as a consequence of this long history of resolving 
domain names using a wide variety of name resolution systems, domain 
names are required in a large variety of contexts in user interfaces 
and applications programming interfaces. Any name that appears in 
such a context is a domain name. So, developers of new name 
resolution systems that must work in existing contexts actually have 
no choice: they must use a Special-Use Domain Name to segregate a 
portion of the namespace for use with their system. 
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6. Security Considerations 


This document mentions various security and privacy considerations in 
the text. However, this document creates no new security or privacy 
concerns. 


7. IANA Considerations 
This document does not require any IANA actions. 
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